1. Field of the Invention
The invention relates in general to circuit emulation systems, in particular to a method for emulating and debugging a circuit design described by a register transfer level netlist.
2. Description of Related Art
A synchronous electronic circuit includes various blocks of logic and a set of clocked memory devices such as registers, latches and flip-flips for transferring signals between the functional blocks. For example, FIG. 1 illustrates a functional block 1 receiving a set of input signals from the circuit's input port's or from other blocks of logic via a register 2 and supplying output signals to the circuit's output ports or to other blocks of logic via another register 3. Registers 2 and 3, clocked by clock signals from the circuit clock distribution system, synchronize state changes in the functional block's input and output signals to edges of those clock signals. Functional block 1 includes a logic block 4 implemented by a set of logic gates and may or may not include other memory devices 5 such as random access memories, registers, and flip-flops and the like for storing data represented by device input signals for generating output signals representing states of the stored data. Logic block 4, which may write access memory devices 5 via memory input and output signals, produces the functional block's output signals as functions of its input signals from register 2 and other memory devices 5.
A circuit designer initially employs a hardware description language (HDL) such as Verilog to create a high level register transfer level (RTL) netlist describing behavior of the circuit's logic by using Boolean expressions to define each signal it produces as a function of the circuit's input signals and/or of output signals of various registers and other memory devices. The designer then uses a computer-aided synthesis tool to convert the RTL netlist into a gate level netlist describing the circuit logic as being implemented by a set of interconnected instances of standard cells such as logic gates and other devices. The designer may later use computer-aided placement and routing tools to convert the gate level netlist into an integrated circuit (IC) layout providing a guide for IC fabrication by indicating the structure, position and orientation of each cell instance within the circuit and by indicating the routes signal paths follow between cell instance terminals.
To determine whether the circuit described by the netlist at any stage of the design process will behave as expected, a designer can program a computer-based circuit simulator to simulate its response to a set of input signals. A simulator program includes an RTL or gate level netlist description of the circuit, specifies the time-varying behavior of the circuit's input signals, indicates which of the circuit's input, internal and output signals are to be monitored during the simulation, and specifies various other parameters of the simulation. The simulator produces waveform data representing the behavior of the monitored signals as a function of time. The designer can then use debugging software to study circuit behavior represented by the waveform data to determine whether the simulated circuit behaved as expected. Debugging software can, for example, produce waveform displays based on the waveform data and provide the designer with various tools for relating the netlist to the waveform data in a way that helps the designer trace sources of signal errors.
As circuit designs have become larger and more complex, designers have found it more time consuming to verify circuit designs using simulation alone, particularly at the gate level. One way to reduce the time needed to verify a gate level netlist design is to employ an emulation system using programmable logic devices to emulate the circuit it describes. Programmable logic devices can emulate circuit behavior much quicker than a simulator can simulate it. For example U.S. Pat. No. 6,377,911 issued Apr. 23, 2002 to Sample et al, describes an emulation system employing field programmable gate arrays (“FPGAs”) that can be programmed to emulate circuit logic.
FIG. 2 illustrates a typical prior art emulation system 10 including a set of circuit boards 12, each holding an array of FPGAs 14, each of which can be programmed to emulate a portion of a circuit. Each FPGA 14 has many I/O terminals and some of those I/O terminals are linked to I/O terminals of other FPGAs 14 on the same circuit board 12 so that the FPGAs can communicate with one another. Circuit boards 12 reside in slots on a motherboard 15 including a backplane for interconnecting I/O terminals of FPGAs 14 residing on different circuit boards 12 so that they too can communicate with one another. In addition to logic FPGAs 14 can emulate, circuits may include large standardized components such as embedded computer processors and memories that can be emulated by processors or memory circuits mounted on resource boards 18 that may also be installed in slots of motherboard 15. The backplane wiring on motherboard 15 also links terminals of the devices mounted on resource boards 18 to I/O terminals of various FPGAs 14 mounted on FPGA boards 12. When emulator 10 is to act as an in-circuit emulation system, the emulator includes an external system interface circuit 22 providing signal paths between I/O terminals of FPGAs 14 and a socket of the external system 24 of the type in which the circuit being emulated will eventually reside. A cable 27 interconnects interface 22 with external system 24 and typically includes a connector that fits into the circuit socket.
Emulation system 10 also includes pattern generation and data acquisition circuits 26 mounted on circuit boards installed in motherboard 15 and linked through the motherboard backplane to I/O terminals of FPGAs 14. These circuits supply input signals to the FPGAs and monitor selected FPGA output signals during the emulation process to acquire waveform data sequences (“waveform data”) representing the behavior of the output signals of the emulated circuit.
A conventional workstation 16 processes the netlist description of a circuit and a description of its testing environment to produce a set of instructions for programming FPGAs 14 to emulate logic of the emulated circuit and transmits those instructions to programming inputs of FPGA 14 via one or more input/output (I/O) interface cards 17 installed in a slot of the PCI bus of workstation 16. Each I/O interface card 17 is capable of transmitting signals to and receiving signals from resources mounted on motherboard 15 via signal paths motherboard 15 provides. During the emulation process, workstation 16 collects waveform data acquired by data acquisition system 26 representing the behavior of circuit signals. When the emulation is complete, the designer can use debugging software that produces graphical displays of circuit signal behavior based on the waveform data and provides displays relating those signals to circuit logic to help the designer determine the sources of any signal errors.
Although the emulator emulates a circuit design described by a gate level netlist generated by a computer-based synthesizer, a circuit designer might prefer to debug the circuit design at the register transfer level because the designer created the RTL netlist and usually finds it easier to understand than the computer-generated gate level netlist. Thus a designer might like a conventional debugger to relate the behavior of various circuit signals represented by the emulator's waveform data to circuit logic described by the RTL netlist. The circuit's input and output signals and the input and output signals of its internal registers and other memory devices appearing in the RTL netlist will also appear in the gate level netlist. However the synthesizer may optimize circuit logic in such a way that not all of the circuit's internal signals appearing in the RTL netlist will also appear in the gate level netlist. For example in the circuit of FIG. 1, the RTL and gate level netlists will both reference the same set of input and output signals of registers 2 and 3 and other memory devices 5, but signals the RTL netlist references as being wholly internal to logic block 4 may not appear in the gate level netlist. This occurs when, as is normally the case, the synthesizer is free to optimize logic block 4 for example to minimize the number of gates needed to implement its logic. Since the eliminated signals do not appear in the gate level netlist, the emulator will not emulate them, the waveform data output of the emulator will not represent them, and the debugger will not be able to directly relate many internal signals of the circuit to the RTL design to any signal represented by the waveform data. This forces the designer to debug the circuit design at the gate level.
For example, an RTL netlist might employ the following Boolean expressions to describe the behavior of logic block 4 of FIG. 1.E=A+C  [1]F=A+D  [2]G=B+C  [3]H=B+D  [4]I=E+F+G+H.  [5]
In this particular example, it is assumed that functional block 1 of FIG. 1 does not include any other memory devices 5. When the designer uses a synthesizer to convert the RTL netlist description of the circuit into a gate level netlist, the synthesizer could produce a circuit design as illustrated in FIG. 3 that directly implements the Boolean expressions using a set of OR gates 44-48. However since such a gate level implementation of the logic of logic block 4 makes inefficient use of circuit resources, a synthesizer will optimize the design of logic block 4 using, for example, two NOR gates 50 and 51 and one NAND gate 52 as illustrated in FIG. 4. The gate level netlist of FIG. 5 preserves the register output and input signals A-D and I referenced by the RTL netlist, but eliminates the internal signals E-H of logic block 4 referenced by the RTL netlist.
The logic optimization performed by the synthesizer not only reduces the number of gates the circuit will need to implement logic block 4, it also reduces the amount of resources the emulator will require to emulate logic block 4. An FPGA includes a set of lookup tables interconnected via registers. Each lookup table may have, for example, up to four input signals and one output signal. An FPGA program defines the logical relationships between each lookup table's input and output signals. As illustrated in FIG. 5, an FPGA emulator may implement the logic of FIG. 4 using a single four-input lookup table. If the gate level netlist were implemented in as illustrated in FIG. 3 in a way that preserves internal signals E-H, then as illustrated in FIG. 6, the emulator would require five lookup tables 56-60 to emulate the functional block. Note that although the gate level design of FIG. 4 maintains the same logical relationship between output signal I and input signals AD, the block's internal signals F, F, G and H described by Boolean expressions [1]-[5] above of the RTL netlist are not available in the emulator implementation of the design illustrated in FIG. 5.
When debugging a circuit design based on the waveform data output of an emulator using lookup table 54 of FIG. 5 to emulate the logic of expressions [1]-[5], the debugging software will not be able to relate signals E-H to the RTL netlist because waveform data representing the behavior of those signals is not available to the debugging software. Although signals E-H are irrelevant to the optimized gate level design, and would not appear in an actual circuit based on the gate level design, those signals are nonetheless relevant to the designer's RTL view of the circuit. If the waveform data output of the emulator indicates that output signal I had an unexpected value at some point during the emulation, a designer viewing the RTL design to trace the source of the error would want to know whether there was an error in the internal logic of that block as represented by expressions [1]-[5] included in the RTL netlist. But since waveform data representing signals E-H does not appear in the waveform data available to the debugging software, the debugger will not be able to relate those expression to signals represented by the waveform data.
One approach to resolving this problem has been to turn off the optimization feature of the synthesizer so that when synthesizing an RTL functional block implementing expressions [1]-[5] above, it produces the non-optimized gate level design of FIG. 3. This results in the emulator configuration of FIG. 6 that preserves signals E-H, thereby making waveform data representing these signals available to the debugging software. However a non-optimized gate level design could require emulation resources exceeding the capacity of the emulator or could substantially increase the amount of time the emulator needs to perform the emulation by increasing the amount of time needed to transfer waveform data from the emulation resources to the workstation implementing the debugger.
What is needed is a system that emulates a circuit described by an optimized gate level netlist but enables a debugger to debug circuit functional blocks at the register transfer level even though the emulator output does not reflect behavior of some of those RTL signals.